home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17457 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.8 KB  |  42 lines
  1. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  2. Path: in1.uu.net!allegra!alice!ark
  3. From: ark@research.att.com (Andrew Koenig)
  4. Subject: Re: Will Java kill C++?
  5. Message-ID: <DpwM4M.KC7@research.att.com>
  6. Organization: AT&T Research, Murray Hill NJ
  7. References: <4ks0c8$jte@piglet.cc.uic.edu> <DpvsE5.2HC@research.att.com> <4ksfdr$bhh@engnews2.Eng.Sun.COM>
  8. Date: Mon, 15 Apr 1996 12:45:57 GMT
  9.  
  10. In article <4ksfdr$bhh@engnews2.Eng.Sun.COM> linden@positive.Sun.COM (Peter van der Linden) writes:
  11.  
  12. > Andrew Koenig <ark@research.att.com> wrote:
  13. > > why aren't you agitating for a name-mangling standard in C?
  14. > > Name mangling is a potential problem there too.
  15.  
  16. > It may be a potential problem, but name mangling isn't an actual problem in C.  
  17. > Names either don't get mangled, or everyone mangles them the same trivial way.
  18.  
  19. That's actually not quite true.  For example, some C compilers put an
  20. underscore at the beginning of external names, and others don't.  I imagine
  21. there are other possibilities too.
  22.  
  23. > Name-mangling in C++ was a grotesque hack (like having the compiler
  24. > implemented as a C-preprocessor).  It provided a compiler 4 months sooner,
  25. > and set the language back five years.
  26.  
  27. Please justify this statement.  You might begin by explaining a different
  28. way of accomplishing what name mangling does -- portably -- in 4 months
  29. of effort or less.  Next you might try to find two C compilers that are
  30. link-compatible in all but their use of external names.
  31.  
  32. > Let's try and face up to the deficiencies of C++.  Not say "well C might
  33. > be just as bad".  When we admit the deficiencies of C++, we can start to
  34. > look for something better.  No programming language is perfect, let's just
  35. > try to make them monotonically better.
  36.  
  37. I completely agree with you.  But that is no excuse for inventing deficiencies
  38. that do not exist.
  39. -- 
  40.                 --Andrew Koenig
  41.                   ark@research.att.com
  42.